今天探討一下面臨重構時該如何是好

測試 - 最重要的一點

重構最怕的問題就是，改一改程式不會動了，由於我們重構要確保不會改變原本的行為模式。在進行重構前就要先將程式碼利用測試做一層保護，才不會等到重構完發現出問題了。

穩定

不知道大家有沒有遇過一個情況，partner上到 github 的分支是未完成的，載下來 run 的時候跳出 error message...
在重構的過程中穩定是非常重要的，重構的方式應該是每一小部分慢慢修正，而不是隨意地覺得「今天這邊先重構，明天再換那邊」。我們應該是完成一個步驟後，通過測試確保沒問題，才能把將重構部分 push 到版本控制系統。

開發與重構的平衡

雖然重構是為了加快開發的速度，但我們不會在同一時間做這兩件事，總不能一直 git stash 切換來切換去的吧，這邊要先確認開發與重構的權重，專心在優先級較高的事項上。

這麼說好了，在新增新功能的時候，你意外看到一個不怎麼嚴重的小bug，通常會先寫在 bug list 上，等開發完再開一個分支修bug吧，這樣也可以確保我們的分支不會有額外的改動。

效能

在重構時，有可能會將架構拆分，導致呼叫的 function 變多了，那這樣直覺上可能會懷疑「效能會不會變差呀...」，這邊我的建議是不要理直覺，真的有效能問題，重構後反而更容易找到他。

對我來說，在重構的當下是不考慮效能這一塊的，重構的目的在於讓程式碼簡潔、易懂，如果真的需要效能調教的話，可以等到重構完再來測試效能，發現效能可以優化再對相關的程式碼進行調教即可。

彈性

在重構時要考慮未來的彈性嗎 ? 我覺得先不用，等到未來有需求再將他託付給未來的自己吧。我們以當下的需求，做最簡化的設計就好。